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METHOD AND COMMUNICATION SYSTEM FOR SIGNALLING INFORMATION FOR OPTIMISING 

RATE CONTROL SCHEMES IN WIRELESS NETWORKS 

This invention relates to a method and communication system for optimising the 
performance of rate control schemes used for sending rate adaptation of packet switched 
streaming (PSS) applications, where a mobile network is the last part of the end-to-end 
communication. 

Generally, to enable the control of the streaming rate, the receiver (mobile terminal) sends 
feedback information to the sender (server). This information is obtained during the data 
transport and it is gathered in the client of the rate control scheme located in the mobile 
terminal. However, since the mobile terminal has link status information from the signalling 
protocol, this link information could be reported to the sender of the streaming application 
Usmg the reported information, the calculation of the sending rate can be adapted to the 
mobile link conditions, and therefore, the quality of the streaming application would be 
improved. 

The number of audio/video streaming applications such as Internet audio player IP- 
telephony, video conferencing etc. is constantly growing and it leads to an increased 
percentage of non-TCP (transmission control protocol) traffic. Since these applications 
commonly do not implement congestion control schemes, the competition with the TCP 
traffic results in a highly unfair situation where the available bandwidth in the network is 
occupied by the PSS traffic. For this reason, rate adaptation schemes are employed in the 
streaming sender, which are compatible to the congestion control algorithm of TCP These 
schemes are applied to the transport protocol used for streaming, e.g. UDP (user datagram 
protocol), and they control the sending rate in such a way that a fair bandwidth distribution 
between TCP and PSS traffic can be achieved. One example for such mechanism is the 
TCP-friendly rate control (TFRC). 

TFRC is specified for unicast communication and adjusts the sending rate based on a 
complex equation that describes TCP throughput. The sending rate is calculated at the 
sender, but to gather the necessary parameters for the equation, feedback Information from 
the receiver is needed. The used TCP throughput equation describes roughly <he sending 
-ete as a function of the loss event ra ,e, round-trip time (RTT) and packet size. The most 
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important information in the feedback message is the loss event rate calculated in the 
receiver. 

A major advantage of TFRC is that it has a relatively stable sending rate (it responds slower 
than TCP to packet losses), but still providing sufficient responsiveness to competing traffic. 
TFRC should only be used when the application has a requirement for smooth throughput. 
Further details about the TFRC can be found in Handley, M., Floyd, S., Padhye, J. and J. 
Widmer "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448 January 
2003. 



The rate control schemes and in particular TFRC described above are developed for wired 
Internet technologies. Since the mobile networks employ recently higher bandwidth wireless 
technologies, the streaming applications will become more popular for the mobile user. 
Especially, in 3rd Generation (3G) mobile networks, e.g. UMTS, streaming services will be 
standard applications provided by the operator. Hence, together with streaming 
applications, rate control schemes need to be implemented. 

The high level architecture of the Universal Mobile Telecommunication System (UMTS) is 
shown in figure 1. The network elements are functionally grouped into Core Network (CN), 
UMTS Terrestrial Radio Access Network (UTRAN) and User Equipment (UE). UTRAN is 
responsible for handling all radio-related functionality, while CN is responsible for routing 
calls and data connections to external networks. The interconnections of these network 
elements are defined by open interfaces lu, Uu as can be seen in the Figure. It should be 
noted that UMTS system is modular and it is therefore possible to have several network 
elements of the same type. 

Figure 2 shows a more detailed view of a UMTS network connected via core network 
elements to an external PDN (packet data network). More specifically, a mobile terminal 
communicates within a cellular communication system comprising a plurality of base 
stations BTS connected to a radio network controller (RNC) to receive and send user data 
and signalling data. The RNC is connected to SGSN (Serving GPRS Support Node) via 
interface Gb, the SGSN serves for delivery of data packets within its service area and 
includes routing, mobility management, authentication, etc. 
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Further, GGSN (Gateway GPRS Support Node) is an interface between the external PDN 
and the SGSN. 



Assuming a packet switched UMTS network, for every active connection at least one 
Packet Data Protocol (POP) context should exist. PDP context is established by end-to-end 
signalling between CN elements (Gateway GPRS Support Node - GGSN) and UE as shown 
in Figure 3. 



From the UE, an activate PDP context request to the SGSN is transmitted including for 
example the PDP type, PDP address, QoS (Quality of Service) requested, access point 
etc. Subsequently, from the SGSN, a create PDP context request is sent to the GGSN 
resulting in a respective PDP context response. The response is transmitted from the 
SGSN to the UE and constitutes acceptance of the requested PDP context. 

The PDP context signalling is transparent to the RAN (radio access network) and therefore 
belongs to the Non Access Stratum. Among the general information in the PDP context 
such as "Traffic Class", it contains parameters as "maximum bit rate for downlink"' 
"guaranteed bit rate for downlink", "maximum bit rate for uplink", "transfer delay" etc After 
establishing PDP context by means of end-to-end signalling, the end-to-end QoS 
information is mapped to RAN specific RAB (radio access bearer) QoS attributes in the CN 
elements (Serving GPRS Support Node - SGSN) and signalled to RAN over lu interface to 
establish an appropriate RAB. Requested attributes may be negotiated between admission 
control function of RAN and CN (SGSN) as described in 3GPP TSG RAN "RAB Quality of 
Service Negotiation over lu", TR 25.946, V.4.0.0. When changing serving cell, a user may 
encounter different conditions (e.g. radio resource availability). In that case, some of RAB 
attributes have to be renegotiated. The re-negotiation procedure (see 3GPP TSG RAN 
"RAB Quality of Service Re-negotiation over lu", TR 25.851 .V.4.0.0) is detailed in figure 4. ' 

Upon reception of the RAB Assignment Request message, the RNC considers the RAB 
modifications agreed to by the CN. If CN has accepted the RNC proposed RAB 
modifications, the RNC makes those modifications and indicates to the CN that the 
appropriate RABs have been modified through the RAB Assignment Response message 
The 'RABs Setup Or Modified' IE (Information Element) group lists the RAB IDs that have 
been modified. If the CN has not accepted the RNC proposed RAB modifications, and has 
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either suggested different RAB modifications or has repeated the previously agreed upon 
RAB parameter values, the RNC decides if that is acceptable to it or not. If acceptable, the 
RNC makes the appropriate RAB modifications, if any, and lists the corresponding RAB IDs 
in the 'RABs Setup Or Modified' IE group of the RAB Assignment Response message it 
sends back to the CN. If the RAB parameter values indicated in the RAB Assignment 
Request message are not acceptable to the RNC, the RNC sends a RAB Assignment 
Response message listing the appropriate RAB IDs in the 'RABs Failed To Setup Or 
Modify' IE group of the message. Lastly, if CN has not accepted the RNC proposed RAB 
modifications, and has requested RABs to be released through the RAB Assignment 
Request message, the RNC releases the appropriate RABs and lists the corresponding 
RAB IDs in the 'RABs Released' IE group of the RAB Assignment Response message it 
sends to the CN. 

It should be noted that negotiated parameters are signalled to the UE by Modify PDP 
Context Message. If the UE deems that the parameters are acceptable, it will send Modify 
PDP Context Accept Message. 

TFRC, as a rate control scheme, probes for available bandwidth over an end-to-end 
communication link and it increases the sending rate until packet losses occur. After a 
packet loss, the sending is halved and it is increased again until the next packet loss event 
occurs. Therefore, packet losses and the resulting reduction of the sending rate lead to poor 
audio/video quality. 

It is important for the quality of every packet switched streaming application that the 
sending/receiving rate remains constant during the time. To meet this requirement in case 
TFRC is used, the packet loss events resulting from the probing for available bandwidth 
should be avoided. 

Therefore, the object of the present invention is to provide a method and communication 
system in which packet loss events in a packet switch streaming application are avoided 
while maintaining an optimal sending rate. 

This object is solved by a method as set forth in claim 1 in a communication system 
comprising the features of claim 5. 
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The invention is based on the idea of adapting the rate control schemes to the conditions of 
the wireless channel using the signalling information already available in the terminal In 
partroular, for every active connection, at least one POP context exists. Consequently when 
PDP context information is exchanged between the receiver of a rate contra! scheme and a 
control plane of the network, which is signalled back to the sender and used for adapting 
the sending rate, the sending rata of the rate control mechanism is limited in such a way 
that packet losses would be avoided. 

The optimisation is achieved by information exchange between Non Access Stratum of 
mobile networks and rate control scheme, in particular, by Information exchange between 
PDP context and rate contra, schemes in the mobile terminal. Providing mis information to 
the rate control scheme in sender, the sending rate can be adapted better to the changing 
oondrttona over the mobile channel, and therefore, the quality of ,he sfreaming application 
could be improved. 

To meet me requirements for low pre^eooder buffer, both packet delay as well as the 
packet delay jitter should be kept possibly low. Applying sending bit rate limitation, packet 
delay and delay jitter could be reduced, and thus, the demands of pre-decoder buffering a. 
the sender are lowered. 

.The invention will be descnbed In the following in further detail with reference to the 
accompanying drawings, which show: 

Figure 1 a high level UMTS architecture; 

Figure 2 a diagram illustrating the communication between a mobi.e terminal and an 
external PDN; 

Figure 3 ^ampie for a PDP context procedure between the mobile terminal and the 

Figure 4 an example for a re-negotiation procedure between the mobile terminal and 
CN elements; and 

Figure 5 illustrates a communication system according to the present invention. 

in figure 5 UMTS network is schema S ca„y shown Including a cellular system served by one 
or more base staaons designated node B. The GGSN provides the connect via an 
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external PDN, i.e. the internet to a streaming application located at a server. The streaming 
application uses the following protocol stack RTP/UDP/IP for streaming data to the mobile 
terminal UE. 

The mobile terminal UE has on the one hand, a mobile link to node B to receive packet data 
and providing feedback on the received packets. Further, a PDP context negotiation can be 
established directly with the core network, i.e. GGSN. A TFRC rate control scheme is 
assumed, where the sending rate is calculated in the sender using feedback information 
from the UE receiver (TFRC client). According to the conventional operation, particularly, 
during the slow start phase the sending rate, X, is approximately doubled each round-trip 
time until a loss occurs and it is calculated according to equation (1), where X_recv is the 
receiving rate at the TFRC client, s is the packet size and R is the round-trip time. 



X = max{ min{ 2*X, 2*X_recv}, s/R } 



d) 



If the last hop of the end-to-end connection is a mobile link, e.g. part of UMTS network, it is 
assumed that the mobile link is the bottleneck link determining the bandwidth limitation. 
During the setup of the connection through UMTS network, PDP context information is 
exchanged between mobile terminal and GGSN, and thus, the mobile terminal has 
knowledge of the bottleneck parameters. 

An interface is defined in the mobile terminal between TFRC client (user plane) and the 
control plane in the receiver for transmitting PDP context information. After receiving the 
first data packet, the TFRC client requires information about the variable service parameter 
"guaranteed bit rate for downlink" from the PDP context information using the defined 
interface. The value of this parameter is signalled back to the TFRC sender via RTSP (Real 
Time Stream Protocol). In the sender, equation (2) for calculating the bit rate is employed, 
where X_max is a new parameter identifying the limitation of sending bit rate and 
corresponding to the signalled parameter "guaranteed bit rate for downlink". 

X = min{ max{ min{ 2*X, 2*X_recv }, s/R }, X_max } (2) 
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Every time a new PDP context is negotiated, and the "guaranteed bit rate for downlink- 
parameter is changed, it should be signalled to the TFRC client, so that the necessary 
update in the sender can be provided. 

As an alternative parameter instead of "guaranteed bit rate" also "maximum bit rate for 
downlink" could be employed for limiting the sending rate. 

The modification of the TFRC algorithm leads to limitation of the maximum allowed sending 
rate that would decrease the likelihood of packet loss events and therefore audio/video 
quality would be improved. 
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